[レポート]DAT378:台帳データベースはどう使う?Amazon QLDB入門 #reinvent

[レポート]DAT378:台帳データベースはどう使う?Amazon QLDB入門 #reinvent

Clock Icon2018.12.04

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

本記事はAWS re:Invent 2018のSession「DAT378 - [NEW LAUNCH!] How do I know I need a ledger database? An Introduction to Amazon QLDB」のレポートです。

Amazon Quantum Ledger Database (QLDB) は re:invent 2018 の1日目のキーノートで発表された新サービスです。

[新サービス] フルマネージドの台帳データベースである、Amazon Quantum Ledger Database (QLDB) が発表されました! #reinvent

Amazon QLDB is probably going to be one of my most favorite launches at #AWS #reinvent https://t.co/gM5BcavXNN

— Werner Vogels (@Werner) November 28, 2018

Amazon QLDB の発表と前後して発表されたブロックチェーンのマネージドサービス(AWS Managed Blockchain)とは別です。ご注意ください。

【速報】【新サービス】AWS Managed Blockchainが発表されました! #reinvent

セッションについて

  • 前半はトップダウンに台帳データベースが必要な背景
  • 後半(22:00〜)はボトムアップに QLDB の動作原理

が解説されています。

本レポートではセッション後半を中心にまとめています。

セッション概要

Do you need a ledger database? Let's talk about the kinds of problems that Amazon Quantum Ledger Database (QLDB) can solve, and answer your questions about when and why you would use a ledger database. We'll showcase a presentation with benefits and use cases for Amazon QLDB.

スピーカー

  • (前半)Chris de Kadt, Director, Amazon QLDB, AWS
  • (後半)Andriew Certain, Sr. Principal Engineer, Amazon QLDB, AWS

メディア

本記事の画像はすべて YouTube 動画をキャプチャーしたものです。

Amazon QLDB のユースケース

Amazon QLDB は中央集権型な

に特化したデータベース。

具体的なユースケースは

  • HR/給与支払い
    • 従業員の肩書
    • 給与支払い
  • サプライチェーン
    • 製品の製造・出荷管理
  • 政府
    • 車の登録手続き

ブロックチェーンと Amazon QLDB の違い

ブロックチェーンは分散台帳技術(DLT) を利用しています。

同じ台帳系技術のこの2つを比較します。

項目 QLDB ブロックチェーン
管理 中央集権 非中央集権
データの更新 イミュータブル イミュータブル
検証可能性 可能 可能
トランザクション処理 速い 遅い
データアクセス SQL風シンタックス 独自

FAQ では次のように記載されています。

Q: Is Amazon Quantum Ledger Database a distributed ledger or blockchain service?

Amazon QLDB is not a blockchain or distributed ledger technology. [SNIP] QLDB is a ledger database purpose-built for customers who need to maintain a complete and verifiable history of data changes in an application that they own.

台帳データベースのコンセプト

  • 台帳(Ledger)はジャーナル(Journal)とテーブルで構成される
  • ユーザーはジャーナルにトランザクション(下図の黒丸)の追記しか出来ない
  • 過去のトランザクションの変更・削除は出来ない
  • ジャーナルをもとに以下のテーブルが更新される
    • 状態(current)
    • 履歴(history)

自動車登録手続きを例に Amazon QLDB の更新フローを考える

  • 登録手続きをトランザクションとしてジャーナルに追記
  • ジャーナルを更新すると、関連する以下のテーブルも自動的に連動して更新
    • 履歴(history.cars)
    • 現在の所有者(current.cars)

レコードの作成→更新→削除のライフサイクルを例に、具体的に確認します。

※注意: DMW は Department of Motor Vehicles のこと

レコードの新規作成

新規に対応するトランザクションログを作成。 ジャーナルにはこのトランザクションしか無いため、current と history は同じ。

INSERT INTO cars <<
{
  'Manufacturer' : 'Tesla',
  'Model' : 'Model S',
  'Year' : '2012',
  'VIN' : '123456789',
  'Owner' : 'Traci Russell'
}

レコードの更新

所有者が変わると、その所有者の情報でトランザクションログを作成。 履歴(history)に追記され、所有者(current)は新しいトランザクションのものになる。

UPDATE cars
SET owner = 'Ronnnie Nash'
WHERE VIN = '123456789'

レコードの削除

廃車などにより登録レコードを破棄する際は、削除に対応するトランザクションログを作成。 履歴を残しつつ、所有者はいなくなる。

DELETE FROM cars
WHERE VIN = '123456789'

伝統的な RDB を利用するなら?

レコード更新イベントに対してストアド・プロシージャを呼び出して

  • 履歴(history.cars)
  • 現在の余裕者(current.cars)

の2テーブル間の整合性を取るアプローチがよく採用されます。

以下の点に注意してください。

  • データの整合性担保は RDB の基本機能として提供されているわけではない。RDBMS の機能を組み合わせて、実現しているだけ。
  • QLDB はデータベースレベルで提供されている。

検証可能性(verifiability)を比較

RDB の場合

  • 車が 2013/08/02 に犯罪で使われた
  • 旧所有者は 2013/08/01 に売却したと主張
  • 新所有者は 2013/08/03 に購入したと主張
  • 登録管理している(伝統的な)データベースに照合すると 2013/08/03
  • データベースの操作履歴も同じ日付

技術的に歴史を書き換えられる(改ざんできる)のであれば、データベースに残る日付(2013/08/03)は信用できない

Amazon QLDB の場合

  • QLDB ではユーザーはテーブルを直接操作することは出来ない
  • QLDB のテーブルはジャーナルのトランザクションをもとに更新される
  • ユーザーが可能なジャーナル操作はトランザクションの追加のみ
  • 過去のトランザクションの削除・変更はできない。
  • トランザクション書き込み時にハッシュ値も記録
  • 一つ前のトランザクションのハッシュ値も利用しているため、どこかのトランザクションが書き換わると、後続のハッシュ値も変わり、検証可能("any possible change in the log is immediately detectable by anyone")

データモデル

データにはどうやってアクセスするのか?

RDB で利用されるリレーショナルモデル

  • 過去40年に渡り、広く使われてきた偉大なイノベーション
  • すべてはトップレベルエンティティ
  • アクセス時に各エンティティをJOINすればよいだけ

ネストされたデータ構造

  • 最近のプログラミング言語はネストされた(高階)データ構造に対応している(JSON など)
  • SQL と相性が悪い

QLDB はドキュメントデータモデルを採用

SQL とドキュメントデータモデルをどうやって両立させたのか?

  • ネストされたデータへのアクセスをリレーショナルモデルの JOIN で表現
  • 「.(ドット)」記法を拡張して実現

例えば次のようにデータがモデルされているとします。

Order {
  id : UUID
  shipping_address : Address
}

Address {
  state: String
}

Order モデルの shipping_addressAddress モデルを参照しています。

Address モデルの state にアクセスするには

SELECT *
FROM orders AS o
WHERE o.shipping_address.state = 'WA'

今後の拡張

  • トランザクション対応
  • スケーラビリティ
  • スキーマ制約(プレビュー時点はスキーマレスで制約なし)

最後に

Amazon Quantum Ledger Database (QLDB) は名前の通り台帳に特化した(purpose built)データベースです。

AWS お得意のフルマネージドサービスであり、SQL 風インターフェースまで用意されているため、Amazon RDS のような他のデータベース系サービスと同じような感覚で操作できるものと思われます。

RDB にいろいろアドオンして台帳に似たデータベースを構築していたり、イミュータブルで検証可能な台帳をほしいがためにブロックチェーンを評価しているユーザーには非常に刺さるのではないでしょうか。

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.